joystick - plan

Document Details

• STATUS:

• Point of Contact: Sayanchowdhury

• Implementation Schedule:

• Release Date:

Goals

To deploy plume as the tool to push Fedora Cloud images to cloud providers, and deprecate fedimg.

Background and Strategic Fit

fedimg has been the primary project uploading the cloud images and Atomic to AWS. fedimg did get a major revamp which gives us a control over the images but fedimg still uses a library which restricts us to do a lot of operation even scaling to other cloud providers.

plume on other hand comes from CoreOS, which has been used to upload Container Linux to various cloud providers.

Migrating from fedimg to plume,

• give the project more set of eyes rather than just one.

• benefit of scaling Fedora to more cloud providers.

• Given both the project, do the same set of job it would be beneficial to have plume replacing fedimg.

People Involved

No one other than the point of Contact

Assumptions and Questions

Are there any assumptions to complete this work?

• We plan to leverage Openshift for deploying the plume work.

• We also plan to use fedora-messaging instead of fedmsg here.

Initial Stories

Personas

• Plume maintainer: A maintainer of the Plume

• Fedimg maintainer: A maintainer of Fedimg

• Joystick maintainer: A maintainer of Joystick, the controller bridge of plume in fedora infrastructure

• Fedora AWS user: A user of the Fedora AMIs on AWS

• Fedora website maintainer: A person who updates fedora websites when there is new Fedora releases

• Fedora 2WA release person: A person who does the 2-week Atomic releases.

• Fedora Infrastructure person: A person from Fedora Infrastructure

Story List

• As a fedimg maintainer, I would like to have provision to add more system in plume so that it is easier to add more OS in the future and not just Container Linux. Acceptance criteria: Extension of plume code to add new system.

• As a fedimg maintainer, I would like to add Fedora as a system so that we can push cloud images via plume. Acceptance criteria: Add Fedora as a system to plume code base

• As a plume maintainer, I would like to see proper integration of new OS'ses so that we don't break our current Container Linux pipeline. Acceptance criteria: CL folks check that the container linux build flow does not break after adding new system.

• As a Fedora website maintainer, I would like to see less change in the flow of the release process, so that during the next release everything works smoothly without much changes. Accpetance criteria: fedora-websites, get-amis script does not break or is update as per required.

• As a Fedora 2WA release person, I would like to see the AMIs are properly uploaded, and not break like it does with fedimg, so that I don't need to go and manually upload or look why it did not upload. Acceptance criteria: Monitor couple of 2WA releases and seeing that they don't break.

• As a joystick maintiner, I would like to see a script that would call plume with the appropriate parameters to upload the images to AWS. Acceptance criteria: A script is added into joystick repo that processes the messages and calls plume, and the appropriate channel.

• As a joystick maintainer, I would like to see that we use fedora-messaging instead of fedmsg, because that would give use more realibility than fedmsg. Acceptance criteria: Fedora messaging both listening and publishing works in joystick script.

• As a Fedora Infrastructure person, I would like to see the app deployed via openshift if possible so that it aligns with our goal to migrate more apps to Openshift. Acceptance criteria: Write a openshift config to deploy joystick as a openshift app

• As a Fedora Infstructure person, I would like to see a RFR in place for the deployment of the project along with the playbooks in our ansible repo, so that we have ways to track the project and manage the boxes for it. Acceptance criteria: File RFR for plume and write the playbooks be it for openshift app or normal VM for both staging and prod.

• As a Fedora AWS, I would like to know that the projects are changing so that I am aware where to report appropriate issues. Acceptance Criteria: Send a sunset email for fedimg.

• As a fedimg maintainer, I would like to deprecate the fedimg project so that we move to use plume full time. Acceptance Criteria: Remove the fedimg boxes, and remove the playbooks after a couple of days, and finally put a deprecation notice on GH repo.

Task breakdown

Plume

• Add the provision in the code to add multiple system.

• Add Fedora as a system into plume

• Test the Container Linux release and build process before the integration of the PR.

• Build Plume RPM [1/2 day]

Joystick

• Write a script to listen to pungi composes and trigger the plume AWS upload process
  • Find the appropriate way to detect channels [1/2 day]
  • Find the appropraite way to detect the image type [1/2 day]

• Write the integration with fedora-messaging
  • Write the config file that would be consumed by joystick's fedora-messaging code [1/2 day]
  • Write the listener consumer [trivial]
  • Write the code that would query the regions to see if the images where uploaded [1 day]
    • Push the appropriate messages for the regions, with as much similarity to earlier fedmsg messages [1 day]

• Write Openshift config to test the deployment as an Openshift App in fedora infrastructure [1 day]

Fedora Infrastructure

• Write a RFR for the new resource for the deployment Comments
  • Smooge agreed to sponsor the RFR.

• Security Audit of the application stack. Comments
  • This is stalling the deployment right now, 28/05, 29/05, 30/05.

• Write the playbooks for the deployment: [1-2 days]
  • [MAJOR CATCH] We would try to deploy it using Openshift, if does not work we need to see how we can.
  • If fails, I would fail to quickly deploy using regular VM

• Test the complete setup in stg [1-2 days]

• Check on how fedimg sunset would be happening. Note the steps that needs to be followed [1/2 - 1 day]

• Send email to Fedora announcements lists about the deprecation of fedimg [ 30 mins ]

Fedora Websites

• Test the compatibility of the get-amis.py or other neccessary scripts. With the new messages in place, we don't want the site generation to break [1 day]

Fedora 2WA

• Closely watch 2-3 releases. [3 weeks]

Fedimg deprecation/Plume deployment

• Deploy plume to production [1 day]

• Follow the steps and deprecate fedimg [1/2 - 1 day]

Phased Release

Phase 1

Add the needed support for plume

Phase 2

Write the script to control plume

Phase 3

Test integration of everything

Phase 4

Deployment and Deprecation.